test(ci): implement cache best practices for github workflows#8820
Merged
test(ci): implement cache best practices for github workflows#8820
Conversation
use the separate actions/cache "restore" and "save" actions so we may only save optional based on whether we are on main or not actions/cache isolates branch caches from main to avoid branch cache poison attacks on main runs but branches may see main cache as those caches are considered trustworthy branch caches do consume available LRU storage though, meaning branch caches could evict main caches and in high traffic / large cache repositories like this one that means caches LRU out frequently and cache hit rates are terrible unless you cache on main only
very occasionally, there are errors in the `hashFiles` function used to calculate cache keys, and this causes a build error that is a flake, not a valid CI failure signal so, continue the workflow even if the caching setup has errors, as that is a recoverable problem and the workflow may still have a valid success outcome
the downloaded/cached files are pure javascript and java, they may be shared across operating systems safely
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
MichaelVerdon
approved these changes
Jan 2, 2026
Collaborator
Author
|
only way to verify workflows (esp when they have "only work on main" conditionals) is to merge and see, so I'm going to do that now If I see anything unexpected I'll post a follow-up plus it will inform changes to the sister PR over in FlutterFire repo |
This was referenced Jan 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
How to review this PR - Each commit in this series is a fully separate idea to improve things, and each should be reviewed separately by reading the commit message which explains that specific change then checking the diff for that commit
The basic idea is this though:
Related issues
A companion to the similar PR developed in FlutterFire repo:
The react-native-firebase repo already had many of the important best practices implemented from my previous work here so doesn't have quite as many changes as the FlutterFire PR
Release Summary
test-only
Checklist
AndroidiOSOther(macOS, web)e2etests added or updated inpackages/\*\*/e2ejesttests added or updated inpackages/\*\*/__tests__Test Plan
Best way to check it is to verify cache hit/miss info from the workflow runs themselves, in combination with a look at the LRU status of the caches for the whole repo (do we have old caches indicating our caches are long-lived and thus more useful?)
can look here https://github.com/invertase/react-native-firebase/actions/caches?query=sort%3Aaccessed-asc
Currently we do have some 3-day-old caches which indicates reasonable utility but there are lots of branch-specific caches and 3 days is not that old, so the changes here should help
Think
react-native-firebaseis great? Please consider supporting the project with any of the below:React Native FirebaseandInvertaseon Twitter